Clearly, without question, the hottest pair of buzzwords in our industry today is client-server. Everybody is using these terms, everybody is doing it and, of course, every vendor has a client-server strategy and associated set of products. Yet, most of us don't fully understand what these two terms really mean. If somebody says they are doing client-server, we have to ask, what are they really doing?
What many of us do understand is centralized transaction processing. Indeed, for many corporations, OLTP has provided the high-performance environment necessary to support a large user base and at the same time ensure that the corporate data remains intact, regardless of failures in system or network components. We understand OLTP, it works, we rely on it and we use it everyday to run our business.
Here we explore the state of these two subjects -- OLTP and client-server -- and suggest a client-server-based application architecture that mixes the two in an effective way. In fact, we believe that this architecture is the basis upon which you will build your future high-volume, mission-critical, client-server-based OLTP applications.
To begin, we must first explore client-server, which is simply the distribution of application processing functions between a client (e.g. PCs, workstations, mainframes, etc.) and a server (e.g. mainframes, workstations, PCs, etc.).
The widely used Gartner model illustrates some of the ways in which application processing functions can be distributed between workstations and servers. In examining the Gartner model, you must first realize that it defines an application program as consisting of three logical groupings of application code -- presentation, application and data access or database management.
From our heritage days, we can easily relate to these breakdowns. The "presentation" code is all the stuff we wrote to display and validate fields on a terminal, while the "database access" code is the stuff necessary to navigate and retrieve information from the database (e.g. Find, Fetch, Getâ•”, etc.). The stuff that's left is the "application function," which performs the rules for the business -- the processing functions for booking orders or flight reservations or updating inventory information. For many of us today, all three of these code groups are hosted within the same program and executed under the control of an OLTP system.
If you take a close look at Figure 1, you can see that client-server is nothing more than a collection of different ways -- models -- in which one can take these three groups of application code and distribute them over a network. So, when someone claims they are "doing client-server," or a vendor claims its product "is client-server," they, in essence, have selected and built an application using one or more of these models.
On the surface, client-server seems quite simple, but as you become more familiar with each of these models you begin to see that each has a set of associated attributes that can help determine when you might select one instead of the other.
To illustrate this, consider those classes of applications in your organization in which there are a large community of users. Your business depends on these applications in order to operate, and they change regularly as the needs of the business changes. Typically, these applications would be built around an OLTP environment.
Now consider the Remote Data Management model in which all application logic is resident on the workstation and the application performs database I/O over the network. Imagine thousands of workstations running this form of a client-server application, all dragging data from the database across the network (gulp!). Imagine having to update and synchronize all these thousands of workstations as you add or change functionality in the application.
Clearly you might want to reconsider choosing this model for this class of application and instead look towards the Distributed Function model, in which you can place as much or as little application logic on the client as desired. In particular, with this model, the application designer can define what the interaction between the client and server will be and, as a result, control what and how much data will flow between the clients and servers. And when all the server-based application functions are contained within a transaction, all the benefits of the OLTP environment are retained. We refer to this as the Remote Transaction Access (RTA) model.
The RTA model
The RTA model is really not all that new. For example, Novell's Tuxedo system for Unix and Digital Equipment Corp.'s ACMS system have exploited this model for years. What is new are products that are bringing this technology to the heritage transaction environments (e.g. TIP, COMS, CICS) that we have been using for years.
Note that RTA combines the concepts behind the Gartner Distributed Function model with the attributes of an OLTP environment. To really understand the attributes of such a combination, you first must understand the Distributed Function model.
When building applications around Distributed Function, the designer/developer has total control over how application logic is split between platforms. What and how much application logic is placed on the desktop and the server is the applications designer's choice.
The most common choice is to put most if not all of the application logic, especially that which may change frequently, on the server. What is likely to be resident on the desktop is the user interface logic and maybe small local application processing logic. Using this breakdown of functionality also permits a great deal of reuse. Application functions located on the server can be reused by several clients running different applications.
The ability to split application logic between platforms requires some new communications software, commonly referred to as communications middleware or, specifically, Remote Procedure Call (RPC) technology. RPC technology facilitates the communication and distribution of procedures or functions throughout a network. It allows you to define a procedural "interface or contract" and "advertise" this contract so that network-based clients may call upon those interfaces as needed.
You should be aware that not all RPCs are the same. There are two open RPC technologies on the market today, ONC RPC and DCE RPC; all others are proprietary, regardless of what the vendor tells you.
ONC RPC was created by Sun Microsystems several years ago and is clearly the most widely used and available (bundled with Unix system). On the other hand, DCE RPC is developed by the Open Software Foundation as an integral part of its Distributed Computing Environment and is relatively new.
Both of these technologies are open, documented by Internet RFCs much like the TCP/IP protocol suite itself, and not singly owned by any company. We urge you to select either one or both of these RPC technologies as opposed to a proprietary technology such as Sybase or Oracle RPCs.
When you take this server-based application logic accessible as procedures on the network using RPC technology, and then "house" it within transactions and use the transaction scheduling, messaging, database and message recovery features of the OLTP environment, you have RTA. From a technological viewpoint, RTA is simply the "marriage" of RPC-based technology with the OLTP transaction manager.
In developing this marriage of RPC and OLTP technologies at DCA, we have architected a couple of different methodologies in which the client participates in the semantics of the transaction environment. One provides a great deal of flexibility, while the other facilitates simplicity. Any good RTA-based product should support both.
In the first case, all of the transaction processing primitives (such as begin transaction, commit, rollback, etc.), as well as some database access primitives (read and write records, scanning the database, etc.), are exposed from the server to the client. Any client can use these primitives with the normal business functions (e.g. add part to inventory) to define transactional boundaries and participate in audit trails and recovery mechanisms. In essence, the client is directly involved in the semantics of transaction processing.
In the second case, all of the transaction processing semantics are handled by the application component on the server. The server defines the transactional boundaries and participates fully in transaction processing just as a monolithic legacy application would.
The server only advertises business functions or procedures on the network for clients to use. Any client simply requests, "Add a part to inventory," supplying the necessary set of inputs. The client has no knowledge of any transactional context.
As you can begin to imagine, using this model can permit a centralized, server-based management of all your application logic. Yet it employs a client-server architecture providing, among other things, a clean separation of the user interface from the bulk of the applications code.
This separation alone facilitates two valuable benefits. First, it allows you to develop other client applications, with their own user interface, reusing the server-based application logic already present. Second, it permits you to "house" key application logic on the server platform, thereby avoiding the duplication of the same in multiple client programs and all of the associated management nightmares.
NetWise Corp.'s TransAccess product suite for IBM MVS mainframes provides the ability to access CICS transactions from non-IBM environments using NetWise RPCs. Likewise, DCA, in conjunction with Unisys, is developing technology which permits RTA to TIP and COMS transactions using open RPC-based technology.
Distributed Transaction Processing
The marriage of client-server and OLTP doesn't have to stop with RTA. There is yet another added level of complexity that can be used in this marriage. It is called Distributed Transaction Processing (DTP).
The DTP model permits a single transaction to be distributed over two or more platforms. This involves coordination across multiple transaction managers and corresponding databases.
With this model, should any "piece" of the transaction fail, the entire transaction fails and all databases involved are rolled back. Using the infamous two phase commit (2PC) protocol, all databases are either updated or rolled back. As you can imagine, the underlying as well as supporting technology is complex and non-trivial to build and manage.
Most believe that the DTP model is best suited for those classes of applications that span multiple platforms and have multiple databases that must be kept synchronized in realtime. By using the 2PC attributes of the DTP environment, one is able to ensure that the databases will be synchronized.
Using a standard, open RPC technology, client-server applications can be built using the RTA model. The RTA and RPC combination provides a high-speed, simple and flexible technology around which to build future transactions for OLTP applications.
When an RTA-based server application needs to be a part of a distributed global transaction, it can use the DTP infrastructure to participate in a global transaction. As shown in Figure 3, the application function or transaction is invoked using RTA-based services on Server1, and it uses the DTP infrastructure to invoke another "subtransaction" on Server2. DTP ensures that both databases are kept synchronized should either piece fail.
While DTP technology is relatively new, there are products on the market today providing these services. Unisys TransIT Open/OLTP, Novell Tuxedo, Transarc Encina, IBM CICS/6000, NCR TopEnd and DEC ACMS are some of the premier products. Most of these are available only for Unix platforms.
OLTP and client-server do mix, and products based on open RPC technology supporting the RTA model are coming. The RTA model is the simplest marriage of the two technologies and permits integration with the more complex DTP technology.
As you embark on building new distributed applications, remember that you are building the legacy applications of your future. Take the time to understand the underlying technologies and methods for building them before you begin. There is much more to client-server than just Visual Basic and Sybase.
Sundar Kadayam and Dave Tillman are senior staff engineers for advanced research at the Unisys Division of Digital Communications Associates (DCA) Inc. in Cincinnati, Ohio.